In mar_IFR_01_v6_60min_saida_hibrida.ntsl.txt, the bSaida exit zone (IFR between 48 and 52) is checked after bCompra and bVenda, but the exit block when bSaida is true (lines 44-47) calls PaintBar(cSaida) but does NOT call PlotText to add a label. This is inconsistent with bCompra and bVenda blocks which do add PlotText when MostrarTexto is true. If this is intentional, a comment would clarify it; otherwise, a text label such as "V6 60 SAIDA" should be added for consistency with the other signal blocks.

The .vscode/settings.json file contains a hardcoded absolute path to a specific user's Python interpreter (C:/Users/zilva/AppData/Local/Programs/Python/Python312/python.exe). This is a machine-specific and user-specific path that will not work on any other developer's machine. Additionally, this file should generally not be committed to version control as it contains personal configuration. The path also reveals a local username ("zilva"), which is a minor privacy concern. Consider adding .vscode/settings.json to .gitignore or replacing the hardcoded path with a relative or workspace-relative path.

In fev_VSAassinaturaInstitucional.txt, corCyan and corFuchsia are assigned the exact same RGB values as corShakeout and corUpthrust respectively:

• corShakeout := RGB(0, 255, 0) (Green)
• corCyan := RGB(0, 255, 0) (also Green — should be Cyan, i.e. RGB(0, 255, 255))
• corUpthrust := RGB(255, 0, 0) (Red)
• corFuchsia := RGB(255, 0, 0) (also Red — should be Fuchsia/Magenta, i.e. RGB(255, 0, 255))

The comments say "Ciano (Compra Extrema/Clímax)" and "Fúcsia (Venda Extrema/Clímax)", but the actual colors assigned are the same as the standard signals, making it impossible to visually distinguish "Volume Extremo" signals from standard ones. The Cyan color should be RGB(0, 255, 255) and the Fuchsia/Magenta color should be RGB(255, 0, 255).

In fev_ATRmovimentoDoPrecoComVontade.txt, the ATR is computed as a simple average of the bar range (High - Low) using Summation / PeriodoATR. This is not a true ATR (Average True Range), which should use the True Range — defined as Max(High - Low, Abs(High - Close[1]), Abs(Low - Close[1])). Using only High - Low will underestimate volatility on days with gaps. The comment on line 31 acknowledges workarounds but the result is a misnamed and functionally different indicator. The variable and the function name FatorVolatilidade imply ATR semantics, which could mislead users of this indicator.

In mar_IFR_03_v45_60min_volume_horario.ntsl.txt, the time format conversion logic has a potential issue. The check if iHoraHHMM > 2400 then iHoraHHMM := Round(iHoraHHMM / 100) is designed to handle times in HHMMSS format (e.g., 103000), but the division by 100 would yield 1030 (correct), yet a time like 235959 would yield 2359, which is a valid HHMM time. However, the input HoraAberturaFim defaults to 103000, which is in HHMMSS format (6 digits), but after the conversion it becomes 1030. The regular Time function in NTSL typically returns HHMM (4 digits) for intraday candles. If Time already returns HHMM format (e.g., 1030), the check > 2400 would never be true for normal session times (max HHMM is 2359), but the HoraAberturaFim default of 103000 (6 digits, HHMMSS) would incorrectly be compared against the 4-digit HHMM time format without conversion. This asymmetry means the condition on line 41 (iHoraHHMM <= iHoraAberturaFimHHMM) would compare HHMM against HHMMSS until the conversion kicks in. The check should be consistent, and the default value should match the expected format.

In fev_VSAassinaturaInstitucional.txt, the Media function is being called with arguments in the wrong order. The standard NTSL signature for Media is Media(Periodo, Serie), but here it is called as Media(Quantity, volPeriod) — the volume quantity series is passed as the first argument (period) and the integer period as the second argument (series). This will produce incorrect results or a runtime error. It should be Media(volPeriod, Quantity).

In fev_HorarioTurbulencia.txt, the condition for Zone 3 (closing/auction, line 34) is logically incorrect. The condition (iHora >= 17) and (iMinuto >= 50) will trigger for any time where the hour is 18 or 19 (regardless of minutes), because when iHora > 17, iMinuto can be any value from 0 to 59 — the minutes condition is not just applied to hour 17. The correct condition should be (iHora > 17) or ((iHora = 17) and (iMinuto >= 50)) to properly capture all times from 17:50 onwards.

In automacao_backtests/NeologicaProfitAPIbacktest.txt, the file contains a plain conversational question ("da para eu usar uma API para buscar os resultados de operação da neologica para o Profit?...") rather than any code, configuration, or documentation. This should not be committed to the repository as it has no technical value and will be confusing to future maintainers.

The file estudo_teorias/0326_diarioDeBordo.md contains only 18 lines of dashes (-----------------------------) with no actual content. This appears to be an empty placeholder that was committed unintentionally. It provides no value to the repository and should either be filled with content or removed before merging.

In fev_VWAPsemanalDiario.txt (line 38), the comment says "Garante que o primeiro candle seja visualmente Cinza (Neutro)" using the condition if (Date <> Date[1]) then PaintBar(corNeutra). However, this condition is true for ALL first candles of EACH new day, not just the very first candle of the entire chart. This means the first candle of every trading day will be painted neutral gray, overriding any buy/sell signal that might have been correctly identified for the first candle of the day. This is likely intentional behavior (avoiding signals on the first bar), but the comment is misleading — it says "primeiro candle" (first candle) but it affects the first candle of every day.